Exchange Mailbox Services Architecture

A database schema is the definition of how the data is stored in the database file. As shown in Table 1, in all earlier versions of Exchange Server, each database has a mailbox, folder, message, and attachment table. These tables are used to store all information for all mailboxes in the database. This provides the ability to only store a message and attachment once for each of the mailboxes in the database. The previous database schema also includes a table for each folder to store the item contents of each folder.

Table 1. Exchange Server 2007 Table Structure

		PER DATABASE		PER FOLDER
MAILBOX TABLE	FOLDER TABLE	MESSAGE TABLE	ATTACHMENT TABLE	MESSAGE/FOLDER TABLE
Terry	Terry: Sent Items	Terry: Message 42	Terry: Word.docx	Terry: Inbox: MH1
Ankur	Ankur: Unread	Ankur: Message 26	Ankur: Manual.pdf	Terry: Inbox: MH2
Joel	Joel: Inbox	Joel: Message 144	Joel: Pricing.xlsx	Terry: Inbox: MH3

Single instance storage no longer provides the space savings that it did when it was first introduced, because of a number of factors. The architecture used to support single instance storage also no longer provides adequate performance for SATA-based storage (this will be covered in more detail later in this chapter). The database structure in Exchange Server 2010, shown in Table 2, was re-architected to now only have one per database table—the mailbox table. All of the folders, message headers, and message bodies are stored in a table for each mailbox. There is also a table for each view, which stores the contents and status of each message included in each view.

Table 2. Exchange Server 2010 Table Structure

PER DATABASE		PER MAILBOX		PER VIEW
MAILBOX TABLE	FOLDER TABLE	MESSAGE HEADER TABLE	BODY TABLE	VIEW TABLES
KC	KC: Sent Items	KC: Message 42	KC: Word.docx	KC: MH1
Jeff	KC: Unread	KC: Message 26	KC: Manual.pdf	KC: MH2
Liberty	KC: Inbox	KC: Message 144	KC: Pricing.xlsx	KC: MH3

This new database structure allows data to be stored contiguously and to keep frequently accessed data located more closely together, as can be seen in Figure 1. When the data is contiguous, the amount of I/O that is required is reduced.

Figure 1. Contiguous database structure

1. Database Files

The mailbox data is stored in the Extensible Storage Engine (ESE) database, which is represented in a number of files that are stored on the Mailbox Server. Each database is represented by a single instance of the ESE instance and shares a single set of transaction log files. Whenever a transaction occurs, ESE first records the transaction in memory to the log buffers and then to a transaction log. The transaction logs contain a history of all the bit-level changes that are committed to the database. In the default database configuration, transaction logs will continue to build up until they are truncated.

Truncation, or deletion of the committed transaction logs, usually occurs when a backup of the database is completed. However, if the database is configured for circular logging, after the transaction logs are committed into the database, the transaction logs are replaced with new transaction logs. Therefore, the most current state of an Exchange service is represented by the database file plus the current log files. Checkpoint files are used to keep track of which transaction logs have been committed to the database. Checkpoint files are named Enn.chk and normally reside in the same directories as the transaction log files.

The basic database files for a database named Dallas-EX01-MB04 are shown in Figure 2.

• Database Name.edb (Dallas-EX01-MB04.edb)

  This file is the B-tree database file. This is where all of the data is stored for mailboxes and in the case of a public folder database where public folder data is stored.

• Enn.chk (E02.chk)

  The checkpoint file contains a record of the committed transaction logs and which logs are yet to be committed. The checkpoint file, as well as many of the other files, is named with the log file prefix, such as E00 for the first database on a server, E01 for the second database, and so on.

• Enn.log (E02.log)

  This is the current transaction log file for the first database. Data is still being written into this file. When the data in this log reaches 1,024 KB or if the server is idle for a period of time, it will be renamed to the next sequential number for the database. A new Exx.log file will then be created, and transactions will be written to it until it is full.

• Ennres00001.jrs and Ennres00002.jrs (E02res00001.jrs and E02res00002.jrs)

  These files are used to reserve emergency storage if the transaction log volume becomes full. In the event that the volume becomes full, these files are deleted to make room for the transactions being processed to be written to disk, and the databases are dismounted. By having two reserved transaction logs, Exchange can reduce the likelihood that transactions will be lost during this process. These files are always 1,024 KB in size.

• Ennhhhhhhhh.log (E0200000A0.log through E0200000A5.log)

  These files are older transaction log files and are named with the log prefix, such as E01, followed by an eight-character hexadecimal number. Thus the file named E0100000001.log is the first log file for the second database on the server. The transaction logs are named with the numbers 1 through 0 and the letters A through F as are used in hexadecimal numbering system. These files will always be 1,024 KB in size. These files are kept until they are truncated—which is done after a successful full backup of the database—or are overwritten after they are committed when circular logging is enabled.

• Tmp.edb

  This file is a temporary workspace for processing active transactions. This file is typically only a few megabytes in size and is deleted automatically when the database is dismounted or the Information Store process is stopped.

• Enntmp.log

This file serves as the transaction log file for the Tmp.edb workspace. This file will never be larger than 1,024 KB in size.

1.1. Single Instance Storage

During the development of Exchange Server, disk capacity compared to I/O capacity was at a premium; to solve this problem, single instance storage was included in the design. Single instance storage writes a single copy of an e-mail message or attachment once in the database and creates pointers for each mailbox in the same database that has a copy of the object, rather than duplicating the data for each copy. This allows a single 1 MB Microsoft Word document to be sent to 200 recipients on the same mailbox database but only be stored a single time, thereby only consuming only 1 MB of space in the database file rather than 200 MB of space. The potential capacity savings in some environments was significant.

A number of changes have happened over the years that have made single instance storage less and less practical. First, mailboxes have become larger. In 1996, it was not uncommon to see a maximum mailbox size of 10 or 25 MB, whereas today 1 GB and larger mailboxes are becoming commonplace. You might think that this indicates that single instance storage is now more important than ever, but this is not really the case. Prior to Exchange 2000 Server there was only an option to create a single Exchange database on the server, which made it possible to use single instance storage across all of the mailboxes on the server. However, now that mailboxes have become larger, more databases are needed on the server to reduce the individual database size, and because the logical boundary for single instance storage is at the database level, the return on single instance storage is diminished with the number of databases that are created.

The Enterprise edition of Exchange 2010 provides you with the ability to create up to 100 databases on a single server, which dilutes the potential for single instance storage savings even more. Hard drives have also become very large in the last 15 years and will continue to increase in size, and Exchange server has become increasingly more efficient at working with lower-performance disk technologies, making space even less of a premium. As a result of this and the performance improvements made in Exchange 2010, single instance storage is no longer included in the product. More information about the decision to remove single instance storage can be found at http://msexchangeteam.com/archive/2010/02/22/454051.aspx.

2. The Exchange Services

The Exchange Server Mailbox role installs a number of unique services. It is important to understand what the Mailbox role does and which services are responsible for specific functionality so that if problems arise they can be pinpointed and corrected quickly. Table 3 lists the services that are installed specifically to support the Mailbox functions.